Récemment la version 102 est sortie. Au fur et à mesure des mises à jours mineures, des choses se sont améliorées ici et là. Côté mail pas grand-chose n’a bougé de l’extérieur mais une réécriture de sections critiques en JavaScript est en cours. Du côté des contacts et de l’agenda, une gestion native des protocoles utilisés par les solutions de partage (tel NextCloud) vient changer la donne. Du côté des messageries instantanées la prise en charge de Matrix a été ajoutée.
Général
Ce qui se remarque d’abord dans une mise à jour, ce sont les changements d’interface. Dans cette nouvelle mouture du célèbre client mail on a droit à une nouvelle barre appelée « barre d’espaces », qui donne un accès rapide aux différents espaces accessibles : mail, contacts, agenda, tâches et messagerie.
Et puis il y a les changements que l’on remarque moins mais qui sont importants. Cette nouvelle version de Thunderbird ne sera pas décevante préparez-vous à modifier et simplifier toute votre configuration.
Pour des questions de sécurité, IMAP et SMTP ont été réécrits de C vers JavaScript.
Il n'existe toujours pas de gestion native d’Exchange via OWA / EWA mais deux plugins se démarquent :
- OWL payant (10 € / an / compte) mais prend très bien en charge les mails, les contacts et le calendrier principal d’Exchange.
- TBSync gère très bien Exchange via son sous-plugin mais est en retard pour la version 102, il reste des bugs. De très longues discussions se demandent que faire, car l’ajout de CalDAV et CardDAV rend ce plugin quasiment obsolète. De plus l’unique développeur est maintenant un employé Mozilla. Tous les détail sont dans la discussion Github.
Un afficheur de PDF a été ajouté de manière native, il est basé sur PDF.js
Agenda
Le support de CalDAV dans Thunderbird existait déjà mais sans découverte. Il fallait rentrer chaque agenda un par un à la main depuis un serveur. Maintenant il existe une découverte automatique, vous rentrez simplement l'adresse principale de votre serveur CalDAV et l'assistant vous proposera d'importer tous les calendriers qu'il trouve. Si jamais vous ne souhaitez pas en importer un tout de suite décochez le. Il vous sera toujours possible de l'ajouter plus tard en refaisant la manip'. Les calendriers déjà importé seront détectés et grisés.
La prise en charge de Outlook CSV a été retirée.
Contact
Thunderbird est passé au format vCard pour stocker les contacts et l’ancienne librairie interne écrite en C, libical, a été remplacé par ical.js.
Ce changement a permis plus de stabilité et surtout un meilleur support du protocole vCard.
Avec la prise en charge native de CardDAV et notamment la découverte automatique il n'a jamais été aussi simple d'ajouter ses contacts stockés dans un NextCloud. Ce support existe depuis la version 91. Ce support a remplacé une autre utilisation de TBSync.
De plus une réécriture complète de la gestion des contacts permet d'avoir enfin une expérience utilisateur digne de ce côté là. Ce qui rend obsolète encore une autre extension : CardBook.
Messagerie
Du côté de la messagerie après Facebook c'est au tour de Google Talk d'être retiré. Dans les deux cas ces plateformes ont arrêté leur passerelle XMPP (Voir l'issue pour Google Talk)
Par contre Matrix a été ajouté aux protocoles existants XMPP, IRC et Odnoklassniki (c’est une messagerie basée sur un réseau social russe nommé ok.ru).
Le client XMPP reste assez pauvre. Par exemple, il n’y a pas de gestion des marque-pages et pas de découverte des groupes de discussions (MUC : Multi-User Chat).
Pour IRC le client est lui aussi très basique. Changement mineur : le serveur par défaut est maintenant LiberaChat. Et dans mon cas il a du mal à me connecter au serveur avec un mot de passe.
Le support des messageries n'a jamais été le grand fort de Thunderbird et, petit avis personnel, je me demande si Thunderbird ne devrait pas totalement laisser tomber ce pan là.
OpenPGP
Il y eu aussi pas de mal de boulot du côté d'OpenPGP :
- une clé peut être rafraîchie depuis un serveur de clés,
- une meilleure intégration depuis la fenêtre de composition des messages,
- un message peut-être déchiffré de manière permanente.
Conclusion
L'extension TBSync qui était vitale avant si on utilisait un CHATONS pour stocker ses calendriers et contacts semble désormais inutile car le support des protocoles de base dans ce domaine est maintenant natif.
Ces dernières nouveautés ont énormément simplifié mon expérience utilisateur et ma configuration. On espère maintenant que ça va continuer sur cette lancée. Par exemple je trouve très étrange qu'il n'y ait pas encore de « Compte » (comme pour les mails et les messageries) pour un serveur CalDAV / CardDAV. Une fois ceux-ci ajoutés on ne peut rien modifier, on peut juste supprimer puis remettre.
De même l'interface d'ajout pour les calendriers et les contacts est bien différente alors que dans le fond ça pourrait être exactement la même du côté utilisateur.
Mais je reste positif et j'ai hâte de découvrir les nouvelles versions !
Aller plus loin
- Un client mail nommé Thunderbird (166 clics)
- Notes de versions de Thundebird (99 clics)
# CategoryManager pas compatible malheureusement
Posté par xandercagexxx . Évalué à 4.
Pour moi (du moins pour des utilisateurs que j'ai fait bsculer sur Thunderbird) il manque encore les catégories pour pouvoir migrer facilement sur la 102
https://github.com/jobisoft/CategoryManager
Mais vu que les différents modules dont tu parles et celui-ci ne sont plus à 100% utile, je sais pas ce qu'il va advenir de ce type de feature non disponible dans la 102.
Wait and see.
# Pour des raisons de sécurité
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 10.
Je croyais que c'était Rust qui était à la mode quand on voulait remplacer C pour des raisons de sécurité ?
[^] # Re: Pour des raisons de sécurité
Posté par antistress (site web personnel) . Évalué à 8.
J'allais poser la question
[^] # Re: Pour des raisons de sécurité
Posté par xoddark . Évalué à 5.
Peut-être que c'est lié aux personnes "disponible" pour travailler sur ce sujet et/ou au fait que le langage soit déjà directement utilisable dans le projet.
Mais en tous cas ça m'a aussi fait tiquer. J'aurais trouvé ça plus judicieux si Rust avait été utilisé pour la ré-implémentation de ses protocoles.
Vu que se sont des composants de base de l'application, la sécurité la légèreté et la fiabilité poussé par Rust m'aurais semblé intéressant.
Mais je ne connais pas toute les raisons de ce choix.
[^] # Re: Pour des raisons de sécurité
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 24 septembre 2022 à 12:41.
Après, Rust est intéressant pour sa sécurité tout en gardant la vitesse d’exécution si j'ai bien lu.
Peut être que les points ré-écrits de TB ne sont pas critiques du point de vue vitesse (comme Pitivi dont l'interface est en python mais le moteur est en C) ? En tout cas je n'avais aucune idée que JS était solide question sécurité, peut-être est-ce une caractéristique des langages interprétés ?
[^] # Re: Pour des raisons de sécurité
Posté par Renault (site web personnel) . Évalué à 8.
On peut discuter de la sécurité mais niveau perfs JS n'est pas un mauvais choix ici.
Même si SMTP et IMAP sont des protocoles de base dans Thunderbird, on utilise essentiellement son interface ou ses données locales, les aspects envoyer / recevoir es messages sont finalement qu'une faible partie de l'usage de Thunderbird et dont les perfs sont bien moins critiques que pour HTTP pour Firefox par exemple.
On passe peu de temps à utiliser ces protocoles avec Thunderbird, donc les perfs ça passe après.
Niveau sécurité je n'en sais rien du tout, une implémentation en C étant risquée aussi.
[^] # Re: Pour des raisons de sécurité
Posté par Arvil . Évalué à 3.
Secondé, d'autant plus que même si je ne connais pas vraiment ce cas je m'attendrais à ce que IMAP/SMTP soient limités par les accès mémoire et réseau et pas CPU bound
[^] # Re: Pour des raisons de sécurité
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
L'argument des personnes disponibles me parait faible puisque Rust est une création de Mozilla. Ils n'utilisent donc pas leur propre langage ?
[^] # Re: Pour des raisons de sécurité
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 10.
Rust a bien été fondé par Mozilla, mais Thunderbird n'est plus développé par Mozilla depuis des années (10 ans peut être ?).
Si je me souviens bien, la communauté Thunderbird s'est prise en main il y a quelques années en montant leur propre fondation (avant ils étaient encore lié fiscalement et avec les outils de développement à la fondation Mozilla).
Personnellement, l'utilisation du JavaScript ne me choque pas: ils ont déjà dû remplacer toutes les définitions XUL/XML de l'interface graphique par du JavaScript pour pouvoir continuer à utiliser la plateforme Gecko.
La petite équipe de Thunderbird a donc déjà des connaissances en JavaScript et continuera d'en avoir besoin encore pendant longtemps.
Pour les add-ons, ils doivent également suivre la plateforme Gecko et donc suivre le nouveau système avec les API en JavaScript (manifest v2 et v3).
Je pense en particulier à la partie agenda qui était l'add-on Ligthning auparavant. Il y a d'ailleurs déjà une bonne partie des fonctionnalités en JavaScript pour la gestion des agendas.
La programmation asynchrone avec JavaScript est vraiment agréable et permet facilement de faire des interactions en gardant la fluidité visuelle et un code de bonne qualité. C'est vraiment efficaces pour avoir en même temps des interactions réseaux lentes et une interface graphique fluide malgré cette lenteur.
Je vois leur utilisation de la plateforme Gecko un peu comme les autres utilisent Electron, mais avec les technologies de Mozilla. C'est donc il me semble naturel de privilégier le JavaScript dans cette situation.
Regarder l'utilisation mémoire brute est une mauvaise mesure, puisque JavaScript a aussi son garbage collector et qu'il peut être plus efficace de garder les objets en mémoire plutôt que de constamment la vider.
Bien sûr, si l'environnement mémoire est restreint le Garbage Collector nettoyera plus souvent la mémoire, mais ça implique que le processeur commence a passer plus de temps à faire des choses inutiles pour l'utilisateur…
On en a parlé ici même et aussi là pour le fait d'utiliser la mémoire disponible.
[^] # Re: Pour des raisons de sécurité
Posté par cg . Évalué à 10.
C'est une histoire mouvementée, on dirait que Thunderbird est plus ou moins revenu dedans : « Thunderbird fait désormais partie de MZLA Technologies Corporation, une filiale détenue à 100 % par la Fondation Mozilla. »
Ce qui ne change rien sur le choix des technos, ils font ce qu'ils veulent hein :)
[^] # Re: Pour des raisons de sécurité
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 5.
Merci pour la précision, j'avais en tête l'article Thunderbird's New Home et, effectivement, ils parlent bien de la MZLA Technologies Corporation et non pas d'une fondation.
[^] # Re: Pour des raisons de sécurité
Posté par Guillaume Maillard (site web personnel) . Évalué à 10.
Passer de C à Javascript c'est surtout encore
consommerutiliser intelligemment plus de ressource processeur et de mémoire vive.Effectivement, Rust aurait été un
meilleurchoix risqué.Mais il y a aussi l'option d'auditer le code C et d'écrire une suite de test complète.Thunderbird fait partie de ces logiciels
qui se dégradent lentement mais surement avec le tempsqui migrent vers les technologies du web 3.0 . Pour gérer mes 4 boîtes emails, ils'accaparen'utilise admirablement qu' un unique gigaoctet de mémoire vive,a des lenteurs et crashs aléatoiresincite son utilisateur a le fermer régulièrement dans un soucis d'optimisation des ressources.L'équipe de développement a clairement pris le chemin de la réécriture totale en JavaScript, une route sans retour au pays
du typage dynamique et autres joyeuseté qu'il est bon de fuir quand on cherche à faire un logiciel performant et fiabledes meilleurs logiciels actuels.Heureusement que l'on a de jolies icônes maintenant, merci la MZLA Technologies Corporation.
[^] # Re: Pour des raisons de sécurité
Posté par antistress (site web personnel) . Évalué à 6. Dernière modification le 24 septembre 2022 à 13:06.
Merci de m'avoir procuré ce rare mélange de rire et de peur :) :/
[^] # Re: Pour des raisons de sécurité
Posté par BAud (site web personnel) . Évalué à 7.
c'est pour ça que j'utilise GNOME Evolution depuis le siècle dernier :-)
[^] # Re: Pour des raisons de sécurité
Posté par TuxMips . Évalué à 1.
Une des conséquences de la "fusion" entre Thunderbird et K9mail ?
[^] # Re: Pour des raisons de sécurité
Posté par jmiven . Évalué à 5. Dernière modification le 24 septembre 2022 à 16:46.
K9 c'est du Java et du Kotlin, il n'y a pour l'instant pas de JS.
[^] # Re: Pour des raisons de sécurité
Posté par iloveibmi . Évalué à 1.
Je plussoie, j'utilise également Evolution depuis une éternité … c'est quand même la première fois que j'entends parler de sécurité avec javascript :-)
[^] # Re: Pour des raisons de sécurité
Posté par Jean-Baptiste Faure . Évalué à 6.
Pour ma part je n'ai jamais de crash avec les binaires fournis par Mozilla, installés dans ~/bin/ (Je suis le seul utilisateur de mon PC).
Et avec 6 comptes, c'est plutôt 400 Mo de RAM utilisés.
[^] # Re: Pour des raisons de sécurité
Posté par reynum (site web personnel) . Évalué à 9.
De mon côté je suis aux alentours de 580M avec 7 comptes et des dizaines de milliers de mails, de plus je ne me souviens plus la dernière fois que j'ai eu un crash de Thunderbird (bon OK je ne l'utilise quotidiennement que depuis 17 ans à l'époque ou il s’appelait "Icedove")
Perso je suis content que TB continue d'évoluer et même si pour des raisons de perfs j'aurais préféré un langage de plus bas niveau que le JS pour recoder certaines parties, je préfère 1000 fois les gens qui font quelque chose à ceux qui se masturbent les neurones sur des choix technologiques/techniques et au final ne font rien.
D'autant plus qu'invoquer le besoin de perfs et d'optimisation de la mémoire pour un client mail franchement faut pas avoir honte :-D
kentoc'h mervel eget bezan saotred
[^] # Re: Pour des raisons de sécurité
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Pour défendre Javascript, c'est aussi une opportunité d'avoir plus de contributeurs.
Rust aurait été un mauvais choix pour ce critère, car les devs risquent de mourir de vieillesse pendant une compilation.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pour des raisons de sécurité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 8.
C'est ce côté poussif qui m'a fait tiquer en voyant débarquer du tout JS ; ça va être de moins en moins à portée de petites configurations. On n'arrête pas le progrès.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pour des raisons de sécurité
Posté par MisterT . Évalué à 3.
Je partage cette inquiétude et confirme la conso mémoire (surtout quand il tourne depuis plusieurs jours). C'est de moins en moins bon. Et le passage en JS est d'autant plus inquiétant… Que se passe-t-il ???
[^] # Re: Pour des raisons de sécurité
Posté par alkino . Évalué à 10.
Je suis à l'origine de la dépêche mais pas le seul contributeur. J'avais à la base simplement noté que plusieurs bouts avaient été passé de C à JavaScript, comme la libical dont je parle dans la partie Agenda. La notion de sécurité a été ajouté par quelqu'un d'autre et cette personne semble bosser pour Mozilla. Je n'ai pas cru bon d'enlever car en effet au sujet de SMTP et IMAP je n'avais pas trouvé de raisons à ce changement. J'aurais sans doute dû reformuler car maintenant du coup la dépêche sonne un peu propagande et les commentaires ne parlent que de ça…
De même un paragraphe un peu méchant dans la conclusion a aussi été retiré par la même personne (en gros je disais que jusqu'ici Thunderbird était sincèrement à la ramasse et que ça faisait du bien de voir bouger le produit vers les standards).
[^] # Re: Pour des raisons de sécurité
Posté par Thomas Capricelli (site web personnel) . Évalué à -2.
C vers Javascript ? Sérieux ? C'est franchement du n'importe quoi.
Et quelle excuse complètement débile ils ont trouvé ? La "sécurité" ?? On dirait un politique qui tente maladroitement de justifier sa dernière loi pro-lobby.
[^] # Re: Pour des raisons de sécurité
Posté par Guillaume Maillard (site web personnel) . Évalué à 10.
D'un autre côté, laisser programmer des web developers agiles frontend/backend [TM] en C, en sachant pertinemment qu'ils n'auront ni l'envie ni la contrainte d'écrire une suite de tests… c'est très risqué, voir dangereux ;)
[^] # Re: Pour des raisons de sécurité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Comme mentionne Adrien, ils font du Gecko là où d'autres font de l'Electron… donc rien de vraiment choquant qu'il y ait plus de JS et sa maîtrise. C'est juste de vouloir s'en justifier par un argument sécuritaire capillotracté qui est nous prend pour des je ne sais quoi.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Pour des raisons de sécurité
Posté par floriang . Évalué à 3.
Je suppose que le mot « sécurité » est plutôt à prendre dans le sens « précaution ».
[^] # Re: Pour des raisons de sécurité
Posté par Dring . Évalué à 10.
J'imagine que l'argument ne porte pas sur le langage et que le débat interne n'a pas été C vs JavaScript. Mais plutôt implémentation maison avec des failles mémoires contre librairie largement utilisée par une communauté plus large.
Si c'est bien ça, l'argument de la sécurité se défend, vraiment.
Je rejoins l'avis général : c'est triste de voir du JS se faufiler partout y compris dans des clients natifs. Mais je me souviens aussi que Thunderbird (et Firefox avant lui) utilisaient XUL, qui était déjà un truc interprété, mal aimé pour sa lenteur et sa consommation mémoire - donc y-a-t-il vraiment une régression ici ?
[^] # Re: Pour des raisons de sécurité
Posté par Zenitram (site web personnel) . Évalué à -10.
L'idée est donc que comme on reproche d'avoir une technologie lente et consommatrice de RAM, on la quitte pour encore plus lent et encore plus consommateur de RAM.
Ou est donc le problème?
Perso je me demande si face à la lenteur de la chose alors qui j'ai une grosse machine, je ne vais pas craquer et passer à Gmail (ou le exchange online de OVH) qui a défaut de consommer moins de RAM est plus réactif. Pas libre mais le libre est un moyen, pas un but, et si les libristes poussent leur utilisateurs à ça…
[^] # Re: Pour des raisons de sécurité
Posté par GG (site web personnel) . Évalué à 3.
Je ne vois pas le rapport entre Thunderbird et Gmail ou Exchange Online.
Il me semble qu'il est possible de se connecter à ceux-là avec Thunderbird. Du moins, c'est ce que j'avais il y a quelques années, quand c'était pas encore trop pénible. Ce n'est pas la faute de Thunderbird si la connexion à Gmail est lente. C'est un choix délibéré de Google. Et vu que maintenant il faut passer un captcha d'abord…
Aucune idée de comment ça fonctionne avec Exchange, ça fonctionnait il y a quelques années. Depuis, j'utilise de vrais serveurs IMAPs.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Pour des raisons de sécurité
Posté par raphj . Évalué à 3. Dernière modification le 25 octobre 2022 à 13:15.
XUL, ce n'était qu'un format permettant de concevoir une interface graphique décrite en XML style HTML mais en utilisant des composants natifs du système (enfin, aussi natifs que possible), animée avec JavaScript, par Gecko, le même moteur que pour HTML/JS. Je doute que passer de XUL à HTML/JavaScript entraîne des ralentissement. On peut d'ailleurs imaginer que c'est plus rapide, parce que les moteurs JS ont eu le temps d'être optimisés à mort depuis l'abandon de XUL, et le rendu HTML est probablement plus travaillé / optimisé que le rendu XUL dans Gecko. L'idée derrière passer de XUL à HTML était de permettre le retrait du support de XUL, on peut supposer que cette simplification permet aussi des optimisations. Mais je ne sais pas si ça a eu lieu, j'ai l'impression que XUL, ça traine encore dans Gecko.
Après, je trouve ça dommage que XUL ait disparu et que des trucs comme Electron ont pris la place que XUL aurait pu prendre (c'était pratique XUL !), et que le passage à HTML dans Firefox/Thunderbird nécessite probablement la maintenance d'un toolkit graphique dédié (probablement moins prenante que la maintenance de XUL) mais ça c'est une autre histoire.
Tout cela étant dit, là on parle d'un passage de C vers JS, pas de XUL vers HTML/JS, espérons que ce passage de C à JS pour l'implémentation des protocoles mail dans Thunderbird ne sera pas source de ralentissements / consommation mémoire significative. L'informatique doit s'alléger maintenant, pas l'inverse. Si ce passage permet de libérer du temps pour optimiser d'autres trucs (plus) significatifs, ça peut être gagnant, indirectement. Je doute que ça soit ça qui se passe, mais pourquoi pas.
[^] # Un peu d'archéologie
Posté par Claude SIMON (site web personnel) . Évalué à 3.
En des temps anciens, je m'étais fendu d'un journal sur XULRunner, qui était à XUL ce que Electron est à HTML. Plus précisément, le journal portait sur la programmation d'applications XULRunner en C++, au lieu du traditionnel JavaScript. Aujourd'hui, j'utilise Electron à la place de XULRunner, mais je suis resté fidèle à C++.
Le journal en question : https://linuxfr.org/users/epeios/journaux/xulrunner-et-c.
Pour les passionnés d'archéologie, les billets de blog référencés dans ce journal peuvent être consultés à cette adresse, le premier se trouvant en bas : https://web.archive.org/web/20120909013202/http://zeusw.org/blog/index.php?categorie5/xul.
Et pour ceux qui veulent encore creuser plus, le code source des programmes mentionnés dans ces billets sont disponibles aux adresse suivantes :
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Pour des raisons de sécurité
Posté par Psychofox (Mastodon) . Évalué à 3.
C'est pas vraiment comme si gmail se bonifiait avec le temps, plutôt le contraire je dirais.
[^] # Re: Pour des raisons de sécurité
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
Le JS dans Firefox et Thunderbird, ce n'est pas nouveau. Ça date de leur version 0.1, et même de leur ancêtre la suite Mozilla (donc depuis 1998…).
Alors une lib de plus ou de moins en JS, ça ne va pas changer grand chose…
Surtout que les moteurs JS d'aujourd'hui, n'ont plus rien à voir avec ceux d'antan, avec le JIT et cie…
Le XUL, c'était du XML. Un HTML++ (de l'époque) sous stéroïde. Rien de plus. Avec du CSS pour le design, et du JS pour le comportement (et un système de composant, XBL, ancètre des web components). Bref, ce qu'on appelle aujourd'hui une appli web.
non.
[^] # Re: Pour des raisons de sécurité
Posté par nlgranger . Évalué à 2.
D'après ce que j'ai compris, c'est très difficile d'écrire une librairie pour imap et smtp à cause du nombre phénoménal d'entorses aux standards dans les serveurs. Je pense que mozilla a répondu à la question: quelle lib est moins pire que la notre mais marche quand même.
[^] # Re: Pour des raisons de sécurité
Posté par lym . Évalué à 2. Dernière modification le 03 novembre 2022 à 14:56.
Surtout en considérant d’où vient Rust :o)
Pas le seul surpris, donc! J'espère que cela ne cache pas le début d'une évolution fâcheuse (client lourd-> web app?).
Mais il semble que JS sorte de plus en plus de son cadre de langage dédié au web dynamique côté client (pendant de PHP côté serveur), poussé par la masse de développeurs web? L'autre exemple en tête qui m'attriste c'est pour le protocole domotique ZWave (l'unique mainteneur de la librairie C++ Open-Zwave ayant claqué la porte depuis bientôt 2 ans) et zwavejs ou la situation est pire (faute de devoir déjà intégrer l'interpréteur, comme Thunderbird, donc pb de dépendances complexes ajoutées réglées malpropre à coup de docker vs la simplicité d'une lib compilée dans l'applicatif qui l'utilise).
Surtout que si je suis assez peu confiant dans la capacité de Rust à remplacer le C dans le codage d'OS/modules/boot-loader, pour de l'applicatif réseau en frontal sur internet et en évolution rapide/constante il semble plus justifié de:
-Se lancer dans un langage nouveau/offrant moins de liberté… et objet, qui a toujours posé le pb de la fine maîtrise de la gestion mémoire/allocations,
-Accepter une petite baisse de perf contre la sécurité intrinsèque,
-Ne pas devoir se reposer sur des outils d'analyse de code, coûteux en ressources, si on veut les perf maximales du C ET la sécurité (ce qui se justifie plus pour du code qui va moins changer dans le temps, ce qui est à mon sens la raison pour laquelle Rust ne percera pas là ou les performances sont le critère premier, car elles ont un coût matériel ajouté évitable donc in-fine évité par l'industrie).
Mais la stratégie de Mozilla est parfois étrange.
# Messagerie
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Comment écrire un plugin pour gérer un nouveau protocole?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Messagerie
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 24 septembre 2022 à 14:42.
bin sur https://addons.thunderbird.net/en-US/thunderbird/ ça te donne accès à
https://addons.thunderbird.net/en-US/developers/
ensuite, enjoy _o/
[^] # Re: Messagerie
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
J'avais déjà consulté ces pages, je ne comprends toujours pas comment faire :-(
Ce n'est pas la première fois que je regarde, depuis des années il n'y a toujours pas un "How to add new chat protocol" ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Messagerie
Posté par Dring . Évalué à 4.
Question naïve : tu as été voir dans les modules existants (IRC, XMPP, …) comment ils "enregistraient" le protocole auquel ils répondaient ?
Je sais, ta question c'est pas "est-ce que je peux y arriver en lisant tout le code de TB", mais est-ce que c'est enfin documenté, mais au cas où…
J'ai été jeter un oeil rapide, ça n'a pas l'air facile à trouver de toute façon.
[^] # Re: Messagerie
Posté par BAud (site web personnel) . Évalué à 2.
ya https://www.ghacks.net/2012/09/28/make-thunderbird-the-chat-powerhouse-add-chat-protocols/ (attention, faut refuser tous leurs cookies :/)
tu peux prendre contact avec le développeur, il te mettra le pied à l'étrier (en plus, il parle sans doute français :p)
[^] # Re: Messagerie
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
This add-on has been removed by its author :-(
https://addons.thunderbird.net/en-US/thunderbird/addon/additional-chat-protocols/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Messagerie
Posté par BAud (site web personnel) . Évalué à 4. Dernière modification le 25 septembre 2022 à 19:26.
peut-être regarder du côté de
https://developer.thunderbird.net/thunderbird-development/codebase-overview/chat/chat-core-protocols
tout n'est pas forcément perdu :-)
ya aussi https://addons.thunderbird.net/en-US/thunderbird/extensions/chat/
[^] # Re: Messagerie
Posté par RoyalPanda . Évalué à 4.
Si si.
Il y a même un tutoriel pour LE protocole que tu veux implémenter, de A à Z, c'est y pas beau.
Par contre il a été écrit en 2026 par un certain « devnewton »
# Tri des comptes
Posté par Maderios . Évalué à 9.
Innovation majeure pour moi: plus besoin d'extension, le tri des comptes est désormais possible dans "account settings", à la souris.
[^] # Re: Tri des comptes
Posté par Stéphane Ascoët (site web personnel) . Évalué à 2.
En espérant que ça fonctionne dans tous les cas de figure. Dans mon université, les comptes de messagerie liés à l'utilisateur sont ajoutés automatiquement. J'avais essayé le greffon et ça avait foutu en l'air tout le profil de la personne…
[^] # Re: Tri des comptes
Posté par DerekSagan . Évalué à 2.
avant je faisais sans greffon et c'était chiant
maintenant ça marche même avec mon compte outlook donc bon :-)
# Formats des boîtes locales
Posté par cg . Évalué à 10.
Thunderbird s'est vachement amélioré, mais selon ma personne et moi-même, il manque un truc tout bête : quand on a sa mailbox en local, c'est une pseudo mbox. Il en découle que l'on ne peut pas partager l'accès à ses mails avec un autre MUA (mutt, par exemple).
Pour décrire ma manière de faire, qui n'est sans doute pas habituelle :
Quand je récupère mes mails (avec getmail en mode IMAP), je les efface du serveur (comportement à la POP3), parce que je suis parano et que je préfère les avoir sur MON ordi et dans mes backups. Le résultat est que quand mon ordi est éteint, mes mails sont inaccessibles, mais c'est justement ce que je veux.
Getmail me fait donc un beau maildir (ou une mbox. Et mutt sait l'utiliser, normal, c'est un format standard. Et aussi formail, et aussi sans doute d'autres lecteurs de mail.
Mais Thunderbird, lui, ne sait pas. Il lui faut soit un serveur IMAP local pour accéder au maildir, soit une version légèrement incompatible de mbox. Il y a un bug ouvert sur ce sujet dans le bugzilla de Thunderbird, mais ça fait genre 10 ans qu'il existe, et trop personne de motivé pour s'y atteler (mais je peux comprendre, en ce qui me concerne, ça dépasse de loin mes compétences en programmation).
Ce qui fait que je ne peux alterner entre Thunderbird et Mutt. Donc je reste avec mutt exclusivement.
[^] # Re: Formats des boîtes locales
Posté par Jean-Baptiste Faure . Évalué à 0.
Quel serait l'intérêt de pouvoir alterner entre Thunderbird et Mutt ?
Ce que tu fais avec Getmail et Mutt je le fais avec Thunderbird tout seul.
[^] # Re: Formats des boîtes locales
Posté par cg . Évalué à 10.
Mutt c'est un exemple, et c'est ce dont je me sers principalement. Pouvoir intégrer Thunderbird en tant que lecteur/rédacteur/expéditeur de messages dans un ensemble d'outils comme formail, procmail, getmail, offlineimap, sendmail (ou nullmailer), emacs-mail, ce serait cool.
Parce que Thunderbird a des extensions chouettes, un moteur de recherche et de filtres assez bon, qu'il permet de visualiser simplement et sans dire des mots choquants à ses collègues les mails qui commence par "mes réponses aux commentaires vert kaki de Judith sont en bleu de Lectoure" :).
Après, je comprend que l'aspect monolithique a aussi des avantages, et je comprend aussi que mon usage est un cas relativement rare.
Je vais donner un exemple pratique, quand même.
Imaginons qu'en temps normal, j'utilise Thunderbird, joie et bonne humeur.
Un jour, je veux lire quelques mails, stocké sur mon ordi, mais mes gamins squattent mon ordi pour regarder un truc débile genre Métropolis de Fritz Lang. Au lieu de les déranger, je fais un ssh sur l'ordi sus-cité, je lance mutt et là, ben mutt aboie car la mailbox n'est pas une mailbox.
Ok, je peux AUSSI faire un
ssh -Y
et lancer thunderbird en remote. Sauf qu'il faut un display X local, ce que je n'ai pas forcément (par exemple, si j'arrive depuis un Mac). Poussons le bouchon plus loin, je peux AUSSI lancer un serveur VNC pour pouvoir lancer Xorg pour pouvoir lancer Thunderbird dans une seconde session. Après tout, j'ai tout le temps, Métropolis dure 2 heures :). Je peux même proposer aux gamins d'enchaîner sur Salo ou les 120 jours de Sodome pour avoir le temps de finir de mettre en place un process permettant de pouvoir lire mon putain de mail, qui dit que mon train est à 19h07 et merde voilà il est 19h12 je l'ai raté, chômage, dépression, alcoolisme, suicide.Sinon, sur le principe, ça porte le doux nom de interopérabilité :D.
En espérant que cette réponse te soit utile, bon week-end.
[^] # Re: Formats des boîtes locales
Posté par Jean-Baptiste Faure . Évalué à 5.
Pas vraiment. J'aurais préféré un exemple sorti de la vie réelle. Là tu exposes un exemple de solutionnisme technologique à un hypothétique problème d'autorité parentale. Je ne vois toujours pas l'utilité de pouvoir accéder à son propre profil Thunderbird avec un autre logiciel que Thunderbird.
Pour partager des données entre 2 clients mail, il y a IMAP, c'est fait pour, non ?
[^] # Re: Formats des boîtes locales
Posté par cg . Évalué à 6. Dernière modification le 25 septembre 2022 à 14:42.
Un autre exemple, alors, très réel. À mon boulot, quand une personne s'en va de l'entreprise, j'archive ses données, puis suppression définitive après 2 ans. Les archives sont un joli tar compressé.
Les données, ce sont :
* le homedir
* la mailbox
* les infos LDAP
De temps en temps, je dois retourner gratter dans la mailbox ainsi archivée pour retrouver une info (car hélas, car les boîtes à lettres sont utilisées comme le stockage fourre-tout/universel favori des utilisateurs, et contiennent parfois des infos qui n'existent nulle part ailleurs).
Donc je untar la mailbox (en maildir), et je peux la lire directement avec
mutt -f lerépertoire
. Pour faire la même chose avec Thunderbird (par exemple pour mettre la boîte à dispo de quelqu'un qui n'apprécie pas le charme de mutt .), je dois passer par un plugin de conversion ou d'import, ou encore remettre la boîte à lettre sur le serveur IMAP, créer un compte bidon le temps de la recherche. Rien d'impossible, rien d'insurmontable. Juste un (petit) regret.Pour résumer, je trouve ça chagrinant de ne pas pouvoir lire une BAL qui soit dans un format standard directement avec Thunderbird.
J'en profite pour faire la promo de l'extension ImportExportTools-NG, qui m'a servi à l'occasion.
[^] # Re: Formats des boîtes locales
Posté par GG (site web personnel) . Évalué à 2.
Est ce que ce ne serait pas plus facile de faire synchroniser Thunderbird sur le serveur IMAPs les données locales, puis ensuite d'archiver ce qui est sur le serveur IMAPs?
Si tu as accès au homedir de l'utilisateur, tu as aussi accès aux comptes mails avec les données locales, de Thunderbird, non?
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Formats des boîtes locales
Posté par Christophe . Évalué à 10.
Le plus logique, c'est quand même d'archiver ce qui est dans un format standard, afin de ne pas s'enfermer dans un unique logiciel.
Je pense qu'il n'y a pas vraiment débat, Thunderbird devrait utiliser le format standard, point. Le reste n'est qu'un ensemble de bidouilles pour contourner ce manque…
[^] # Re: Formats des boîtes locales
Posté par GG (site web personnel) . Évalué à 2.
Y a plus qu'à motiver un contributeur…
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Formats des boîtes locales
Posté par Zenitram (site web personnel) . Évalué à -4. Dernière modification le 24 septembre 2022 à 17:37.
Wow, ha ouais, quand même, à l'heure du multi-device et connecté, on est pas mal dans l'imagination pour la compétition de trouver l'inconfort le plus bizarre.
Tu m'étonnes, vu que pour 99.999% de la population ils utilisent juste IMAP pour ce pour quoi il a été conçu. Et que pour 99.9% (j'enlève des 9 car pas assez de monde) des restants ils ne voient pas l’intérêt d'utiliser 2 logiciels pour faire la même chose.
Du coup, va falloir trouver un autre cas d'usage pour motiver des tiers, ou t'y coller.
[^] # Re: Formats des boîtes locales
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
On peut choisir de nommer cela inconfort ou de l'appeler par son nom habituel : archivage…
D'un autre côté, ce n'est pas parce-que tout le monde est éparpillé et à poil qu'il faut se sentir obligé-e de suivre la troupe…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Formats des boîtes locales
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5.
Où être dépendant d'un appareil ! Une question à se poser est : est-il vraiment indispensable d'accéder tout le temps à sa messagerie électronique, la raison est, bien souvent, non !
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Formats des boîtes locales
Posté par Maderios . Évalué à 4. Dernière modification le 23 octobre 2022 à 21:05.
Tout dépend de ton mode de vie, de ton lieu d'habitation, de l'éloignement de tes proches, etc. Quand on sa famille à des milliers de Km, c'est un lien qui est plus qu'utile, surtout en période de COVID/confinement.
[^] # Re: Formats des boîtes locales
Posté par xcomcmdr . Évalué à 2.
QUOI ?!
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Formats des boîtes locales
Posté par Jean-Baptiste Faure . Évalué à 5.
Pour diverses raisons, je ne fais plus confiance à mon FAI pour conserver mes courriels, donc je les déplace ailleurs. Qu'est-ce qui te choque là dedans ?
[^] # Re: Formats des boîtes locales
Posté par Zenitram (site web personnel) . Évalué à 6. Dernière modification le 25 septembre 2022 à 09:58.
Généralement les gens qui n'ont plus confiance dans leur hébergeur mail (choix indépendant du choix de FAI, même si un FAI propose un oackage on n'a aucune obligation d'utiliser) changent d'hébergeur mail.
Et si la personne est attachée à son indépendance ça sera transparent pour ses contacts çar elle aura pris soin d'avoir une adresse mail d'un domaine qu'elle possède (B.A.ba de l'indépendance depuis plus de 20 ans, depuis que les FAI utilisent leur nom de domaine pour attirer).
Au final j'ai l'impression que l'argument sur le besoin montre in problème très différent.
(Ce qui n'empêche pas de développer ou faire développer, si le besoin est réel, et si d'autres ont le même besoin le coût peut se mutualiser, mais changer d'hébergement mail sera dans tous les cas moins cher)
Si que conserver, ben on peut backuper sans supprimer, difficile à suivre la logique.
En plus l'argument ne répond pas à la question de pourquoi ne pas utiliser POP3 pour faire comme du POP3, plutôt que de scripter IMAP.
Ça doit plus amuser que choquer.
[^] # Re: Formats des boîtes locales
Posté par cg . Évalué à 9.
C'est aussi simple d'utilisation, point de scripting là-dedans, je fais
getmail -d
, ça récupère mes messages et les efface du serveur. IMAP prévoit plein de bonnes choses pour organiser ses messages en dossiers et faire de la recherche côté serveur, mais en aucun cas ne t'oblige à le faire. La fonction de suppression fait même partie du protocole depuis la première version ;).Après, on peut me considérer comme déviant :p de ne pas pouvoir accéder à mes mails de n'importe où n'importe quand. Perso je trouve que c'est un avantage, comme ne pas avoir de smartphone, par exemple.
[^] # Re: Formats des boîtes locales
Posté par Faya . Évalué à 9.
Ton cas d'usage est hyper-spécifique et je pense qu'il occulte le principal argument : ça serait cool que Thunderbird respecte les standards établis. Il existe mbox & maildir mais Thunderbird utilise un fake-mbox incompatible. Ne serait-ce que pour des questions d'interopérabilité il serait bon d'évoluer.
mbox
est antédiluvien, mon Inbox se retrouve stockée dans un unique fichier de plusieurs gigas. Alors quemaildir
a été créé pour le remplacer. Wikipédia dit même "Il est de plus particulièrement adapté pour les agents de distribution du courriel compatibles avec le protocole IMAP." Par exemple de mon côté, j'aimerais bien pouvoir faire des sauvegardes incrémentales automatiques pour ne pas transférer 2Go à chaque backup de mon profil TB.[^] # Re: Formats des boîtes locales
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Donc vous êtes tous les deux d'accord qu'utiliser maildir et non un autre standard serait top. Accessoirement pouvoir lire/importer mbox serait un plus.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Formats des boîtes locales
Posté par Stéphane Ascoët (site web personnel) . Évalué à 2.
Connais-tu https://addons.thunderbird.net/en-US/thunderbird/addon/importexporttools-ng/ ?
Sur un antédiluvien Icedove 3, j'utilise toute une batterie de greffons ayant des fonctionnalités proches qui étaient faits par un asiatique je crois.
[^] # Re: Formats des boîtes locales
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Intéressant. À tester à l'occasion cg ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Formats des boîtes locales
Posté par Faya . Évalué à 7. Dernière modification le 26 septembre 2022 à 15:52.
Oui. C'est ce que j'attends impatiemment.
[EDIT] Ouais, c'est du libre, faut contribuer mais je sais pas faire. Donc je ne vais pas leur cracher dessus, surtout qu'ils parviennent à maintenir un logiciel à contre-courant des divers webmails… Donc je prends mon mal en patience et je croise les doigts.
[^] # Re: Formats des boîtes locales
Posté par YannickP . Évalué à 6.
Pourquoi ne pas monter un serveur IMAP local ?
[^] # Re: Formats des boîtes locales
Posté par cg . Évalué à 2.
En effet, c'est peut-être encore la meilleure solution.
[^] # Re: Formats des boîtes locales
Posté par jeberger (site web personnel) . Évalué à 5.
Thunderbird savait, mais la fonctionnalité a été retirée après la version 78: https://bugzilla.mozilla.org/show_bug.cgi?id=1727931
Il y a 3 mois, ils parlaient de le remettre mais pour l'instant ce n'est pas fait…
[^] # Re: Formats des boîtes locales
Posté par bbo . Évalué à 3.
La vraie question que je me pose : est-ce que ça sera ré-implémenté en JS ?
;-P
[^] # Re: Formats des boîtes locales
Posté par Stéphane Ascoët (site web personnel) . Évalué à 2.
Je ne sais pas à qui jeberger répond, mais ça m'a permis de découvrir ce nouveau scandale, même si, vu le nombre de tickets ignorés(certains pendant 20 ans, de fonctionnalités essentielles comme le bug dans la notification de nouveaux courriels qui n'a lieu qu'une fois) ou rejetés, je n'ai pas attendu cela pour ne plus rien attendre de valable des développeurs Mozilla(ou leurs successeurs). Je rêve de passer à Sylpheed/Claws mais vu mon historique d'utilisation de Icedove/Thunderbird, j'ai trop peur de la migration.
Tu ne crois pas si bien dire:
Ce qui semble être la liste des tickets que j'ai déposé est sur: ici
et commentés
Du coup j'ai retrouvé l'adresse du site avec mes extensions chéries
Pas très sympa de sa part de pénaliser les utilisateurs, dont des libristes, pour lutter contre la dictature nazitaire
[^] # Re: Formats des boîtes locales
Posté par Stéphane Ascoët (site web personnel) . Évalué à 1.
Le projet Betterbird m'a fait sa publicité car j'étais intervenu dans un des tickets suite à la série de commentaires ci-dessus. Je n'ai pas encore testé(notamment parce qu'ils n'ont pas de paquet Debian). C'est dans la pile des milliards de choses que je n'aurais jamais le temps de faire(et en plus ça rentre en concurrence avec mon rêve de passer à Sylpheed/Claws).
[^] # Re: Formats des boîtes locales
Posté par sifu . Évalué à 6.
Il faut aussi noter que le support Maildir à la sauce Thunderbird n'est pas encore stabilisé.
Cf.
https://support.mozilla.org/fr/kb/maildir-thunderbird
Personnellement, pour les sauvegardes incrémentales, j'attends avec impatience.
# Authentification IMAP pour office365 (raison: inquiétude)
Posté par FantastIX . Évalué à 3.
J'ai cru voir passer il y a quelques semaines un avis sur l'obsolétisation (sic) prochaine sur Office 365 de l'authentification IMAP par mot de "passe de base". Est-ce bien d'actualité? Je ne parviens pas à retrouver l'article que j'ai vu passer, d'où ma question.
L'extension OWL¹ (Chouette en français, apparemment), sous licence expire prochainement et j'observe des "bizarreries" du genre délais extrêmement longs à l'envoi de mails mais pas partout — du moins pas tout le temps mais j'ai du mal à détecter un motif. Est-ce toujours une solution viable? Ou bien le seul recours est-il d'utiliser l'interface web d'Outlook 365?
¹ Que j'ai installée sur un compte de test.
[^] # Re: Authentification IMAP pour office365 (raison: inquiétude)
Posté par alkino . Évalué à 1.
Je m'en sers depuis ~ 2 ans et je n'ai jamais eu de soucis avec les mails. La synchro des agendas est des fois très lente, mais c'est tout.
[^] # Re: Authentification IMAP pour office365 (raison: inquiétude)
Posté par FantastIX . Évalué à 2.
Merci pour ton retour mais les ralentissements ne sont pas ma principale préoccupation…
[^] # Re: Authentification IMAP pour office365 (raison: inquiétude)
Posté par jahman . Évalué à 2. Dernière modification le 26 septembre 2022 à 18:56.
Bonjour,
J'en ai aussi entendu parler (de mémoire juste avant la crise covid) je ne sais pas ou cela en est côté microsoft.
arret de la “Basic Auth” sur Azure et d'IMAP (thunderbird)
https://techcommunity.microsoft.com/t5/exchange-team-blog/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/ba-p/608055
et
https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-april-2020-update/ba-p/1275508
EDIT: c'est finalement pour tres bientôt (début octobre 2022 sur certains clients)
Texte du lien
[^] # Re: Authentification IMAP pour office365 (raison: inquiétude)
Posté par FantastIX . Évalué à 9.
Ouais, bon, comme d'hab, quoi. Plutôt que de forcer TLS avec l'authentification de base, Microsoft sort son arme nucléaire et fume le protocole. Pourquoi être flexible quand on peut faire chier le monde…
[^] # Re: Authentification IMAP pour office365 (raison: inquiétude)
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 9.
Si cette entreprise avait du savoir-faire et pas de mauvaise foi, ça se saurait. De plus ç'a toujours été dans son ADN de massacrer les standards dans l'espoir d'imposer sa came.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Authentification IMAP pour office365 (raison: inquiétude)
Posté par quent57 . Évalué à 2.
Merci pour l'info !
mon compte mail office365 ne se synchronisait plus depuis hier soir, mot de passe refusé…
Idem pour TBSync, en rade depuis hier soir.
J'ai essayé avec OWL, et cela fonctionne à merveille :)
OWL récupère les mails, mais aussi l'annuaire de contacts et l'agenda.
[^] # Re: Authentification IMAP pour office365 (raison: inquiétude)
Posté par FantastIX . Évalué à 3.
De rien. Fais juste gaffe car OWL (ou Chouette) est sous licence propriétaire et payante. Tu as en réalité une version fonctionnelle pendant un mois. Passé ce délai, tu dois
acheterlouer la licence¹. Tu peux aussi activer OAuth2 — c'est ce que j'ai fait.Attention, cependant, que OAuth2 requiert le second facteur d'authentification, c-à-d un email ou numéro de téléphone supplémentaire² (tout comme Google). Je ne recommande pas le second mais un compte email créé exprès pour le 2FA Office365, histoire d'empêcher le croisement des données d'identification.
¹ 10€ par an.
² Que quelqu'un me corrige si je me plante, bien entendu. Pour ma part, l'authentification OAuth2 ne fonctionnait pas correctement jusqu'à ce que je complète le "formulaire" 2FA de 'crosoft.
# OWA !!! Oh non !
Posté par bepolymathe . Évalué à 1.
De mon côté il n’y a pas moyen (ni avec OWL, ni autre chose) de faire fonctionner mon compte pro OWA avec Thunderbird et j’en suis fâché. L’identification se fait bien avec OWL mais il n’arrive à récupérer les mails ensuite pour les intégrer dans thunderbird. Dommage.
[^] # Re: OWA !!! Oh non !
Posté par alkino . Évalué à 2.
Ni autre chose c'est aussi TBSync?
[^] # Re: OWA !!! Oh non !
Posté par FantastIX . Évalué à 3.
As-tu essayé OAuth2?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.